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Abstract 

Effect systems have the potential to help software developers, but 
their practical adoption has been very limited. We conjecture that 
this limited adoption is due in part to the difficulty of transition- 
ing from a system where effects are implicit and unrestricted to a 
system with a static effect discipline, which must settle for con- 
servative checking in order to be decidable. To address this hin- 
drance, we develop a theory of gradual effect checking, which 
makes it possible to incrementally annotate and statically check 
effects, while still rejecting statically inconsistent programs. We 
extend the generic type-and-effect framework of Marino and Mill- 
stein with a notion of unknown effects, which turns out to be sig- 
nificantly more subtle than unknown types in traditional gradual 
typing. We appeal to abstract interpretation to develop and validate 
the concepts of gradual effect checking. We also demonstrate how 
an effect system formulated in Marino and Millstein's framework 
can be automatically extended to support gradual checking. 

Categories and Subject Descriptors D.3.1 [Software]: Program- 
ming Languages — Formal Definitions and Theory 

Keywords Type-and-effect systems; gradual typing; abstract in- 
terpretation 

1. Introduction 

Type-and-effect systems allow static reasoning about the compu- 
tational effects of programs. Effect systems were originally in- 
troduced to safely support mutable variables in functional lan- 
guages 1 1 1|, but more recently, effect systems have been developed 
for a variety of effect domains, e.g., I/O, exceptions, locking, atom- 
icity, confinement, and purity [T2l fT3l fT71 [T8l ■ 

To abstract from specific effect domains and account for ef- 
fect systems in general, Marino and Millstein (M&M) developed 
a generic effect system 1 15 1. In their framework, effect systems are 
seen as granting and checking privileges. Genericity is obtained 
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by parameterizing the type system and runtime semantics of a lan- 
guage with two operations, called adjust and check, which respec- 
tively specify how the set of held privileges is adjusted and checked 
during type checking. A particular effect system is instantiated by 
providing a syntax for effects and a definition of the check and ad- 
just operations. They demonstrate that several effect systems from 
the literature can be formulated as instantiations of the generic 
framework. 

The generic effect system underlies the design of the Scala 
effect checker plugin, which extends the M&M framework with 
a form of effect polymorphism 1171 . Several specific effect systems 
for this plugin include IO effects, exceptions, and more recently, 
state effects fl8l . 

Despite their obvious advantages in terms of static reasoning, 
the adoption of effect systems has been rather limited in practice. 
While effect polymorphism supports the definition of higher-order 
functions that are polymorphic in the effects of their arguments 
(e.g., map), writing fully-annotated effectful programs is complex, 
and is hardly ever doner] 

We conjecture that an important reason for the limited adoption 
of effect systems is the difficulty of transitioning from a system 
where effects are implicit and unrestricted to a system with a fully 
static effect discipline. Another explanation is that effect systems 
are necessarily conservative and therefore occasionally reject valid 
programs. We follow the line of work on gradual verification of 
program properties (e.g., gradual typing |22 23], gradual owner- 
ship types |21|, gradual typestate 1 10, 26|), and develop a theory of 
gradual effect systems. Our contributions are as follows: 

• We shed light on the meaning of gradual effect checking, and its 
fundamental differences from traditional gradual typing, by for- 
mulating it in the framework of abstract interpretation (4). Ab- 
stract interpretation allows us to clearly and precisely specify 
otherwise informal design intentions about gradual effect sys- 
tems. Key notions like the meaning of unknown effects, consis- 
tent privilege sets, and consistent containment between them, 
are defined in terms of abstraction and concretization opera- 
tions. 

• We extend the generic effect system of Marino and Millstein 
into a generic framework for gradual effects. As with gradual 
typing, our approach relies on a translation to an internal lan- 
guage with explicit checks and casts. The nature of these checks 
and casts is, however, quite different. We prove the type safety 
of the internal language and the preservation of typability by 
the translation. 

• We demonstrate how an effect system formulated in the M&M 
framework can be immediately extended to support gradual 
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checking by lifting existing adjust and check functions to the 
gradual setting. 

• We present a concrete instantiation of the generic framework 
to gradually check exceptions. The resulting system is compact 
and provides a tangible and self-contained example of gradual 
effect checking. 

We believe this work can help effect system developers extend 
their designs with support for gradual checking, thereby facilitating 
their adoption. 

2. Background and Motivation 

In this section, we introduce the idea of static effect checking, and 
give an intuition for how gradual effect checking is related. We 
finish with a brief introduction to the M&M generic framework for 
specifying type-and-effect systems. 

2.1 Effect Systems 

Effect systems classify the computational effects that an expression 
performs when evaluated. To illustrate this idea, consider a simple 
functional language with integers, booleans, and references. We 
focus on three mutable state effects: alloc, read and write. 

A value such as 7 or ( Ax : Int . x) has no effect; neither does an 
arithmetic expression whose sub-expressions have no effect, such 
as 7 + 12. Conversely, creating a reference such as ref 6 has type 
Ref Int and effect alloc. Similarly, an assignment expression 
such as x := 2 has type Unit and effect write, and dereferencing 
a reference \x has the type of the reference content, and effect read. 

Since functions are values they have no effects, but they may 
perform effects when applied. To modularly check effects, then, 
function types are annotated with the effects of the function body. 
For instance, the function /: 

f = Ax : Ref Int . ! x 

has type (Ref Int) Int because a read effect happens during 
the application of the function. Note that the effect may not hap- 
pen during some applications of a function, for instance (assuming 
y : Bool is in scope): 

g = Ax : Ref Int . if y then x := 3; 0 else 1 

has type (Ref Int) ^Int because its applications may perform 
a write effect. 

Of course, an expression can induce more than one effect, hence 
the use of effect sets in the annotations. Though the language does 
not define any notion of subtyping on types themselves, effect sets 
leads to a natural notion of subtyping |25|. Consider the following 
higher-order function: 



h : ((Ref Int 



{read, alloc} 



Int) 



>Int 



This function restricts the effects of its function argument to 
{read, alloc}. Intuitively, it is valid to apply h to /, whose effect 
set is {read}, because that would not violate the expectations of 
h. In other words: 

, , {read} , . {read.alloc} 

(Ref Int) — /int <: (Ref Int) Int 

because the effects of the former are a subset of the latter. Con- 
versely, it is invalid to apply h to g. 

From effects to privileges. Following Marino and Millstein 1151 , 
we interpret effect systems in terms of privilege checking: to each 



effectful operation corresponds a privilege required to perform it. 
For instance, we can view alloc, read and write as the privileges 
required to respectively allocate, dereference and assign a refer- 
ence. In this framework, the function type (Ref Int)*— ?Int is 
interpreted as the type of a function that requires the read privi- 
lege in order to be applied. Effect checking ensures that sufficient 
privileges have been granted to perform effectful operations. 

2.2 Towards Gradual Effect Checking 

Programming in the presence of a statically checked discipline 
brings stronger guarantees about the behavior of programs, but 
doing so is demanding. In addition, one is limited by the fact 
that the checker is conservative. Recently, several practical effect 
systems have been applied to existing libraries, and the empirical 
findings highlight the need to occasionally bypass static effect 

checking nana. 

For instance, the JavaUI effect system 1121 . which prevents 
non-UI threads from accessing UI objects or invoking Ul-thread- 
only methods, cannot be used to verify libraries that dynamically 
check which thread they are running on and adapt their behavior 
accordingly. As explained by the authors, the patterns of dynamic 
checks they found in existing code go beyond simple if-then-else 
statements and so cannot be handled simply by specializing the 
static type system. While JavaUI lives with this limitation, the Scala 
effect plugin 1 17 1 has recently been updated with an Ounchecked 
annotation to simply turn off effect checking locally. The use of 
this annotation however breaks the guarantees offered by the effect 
system, since there are no associated runtime checks. 

In the realm of standard type systems, gradual typing |; 23l is 
a promising approach that alleviates the complexity and conserva- 
tiveness issues by integrating static and dynamic checking seam- 
lessly and safely. The appeal of gradual typing has inspired the de- 
velopment of gradual approaches to a variety of type disciplines, 
including objects 1 14, 22 24|, ownership types 1211 . typestates 1101 
[26), and information flow typing (6). 

This paper develops gradual effect checking, following the core 
design principles that are common to all gradual checking ap- 
proaches: (a) The same language can support both fully static and 
fully dynamic checking of program properties, (b) The program- 
mer has fine grained control over the static-to-dynamic spectrum. 
(c) The gradual checker statically rejects programs on the basis that 
they surely go wrong; programs that may go right are accepted stat- 
ically, but subject to dynamic checking, (d) Runtime checks are 
minimized based on static information, (e) Violations of properties 
are detected as runtime errors — there are no stuck programs. 

2.3 Gradual Effects in Action 

Recall the function g defined in Sec. |2.1| which requires {write} 
privileges. The program h g is rejected because h only accepts 
functions that require {read, alloc} privileges. Even if the pro- 
grammer knows that for a particular use of g, the if condition y is 
false — and thus needs no write privilege after all — the program is 
rejected. 

In direct analogy to the unknown type ? introduced by Siek 
and Taha [23] for gradual typing, we introduce statically unknown 
privileges, denoted i, to our language. One can ascribe unknown 
privileges to any expression e, using the notation e :: For in- 
stance, if g is defined as: 



Ax : Ref Int . if y then (x 

ill 



3;0) 



. else 1 



then it is given the type (Ref Int)-^4lnt. The application h g is 
now statically accepted by the gradual effect system. At runtime, 
if only the else branch is ever executed, then no error occurs. If, 
on the other hand, the programmer wrongly assumed that g would 
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not require the write privilege and the then branch is executed, 
an effect error is raised, preventing the assignment to x. 

The ascription expression e :: i introduces dynamic checking 
semantics. Statically, it hides the privileges required by e from the 
surrounding context, and allows the subexpressions of e to attempt 
effectful operations. At runtime, checks occur to ensure that the 
static privileges that e requires are available as needed. 

One can partially expose (and hence dynamically check) re- 
quired privileges by ascribing specific privileges in addition to I. 
For instance, e :: {read, 1} statically reveals that e requires the 
read privilege, but hides other potential requirements]^ 

The static-to-dynamic spectrum We have illustrated the use of 
gradual effect checking from the point of view of "softening static 
checking" — introducing islands of dynamicity in an otherwise 
static verification process. Gradual verification is about supporting 
both ends of the static-to-dynamic spectrum as well as any middle 
ground. We now discuss gradual effect checking from the point of 
view of "hardening dynamic checking" — introducing static checks 
in an otherwise dynamic verification process. 

A fully-dynamic effectful program corresponds to a gradually- 
typed program without any effect-related annotations in which all 
effectful operations are wrapped by a :: i ascription|^]static check- 
ing trivially succeeds because all expressions hide their required 
privileges. Forbidden effects will only be detected at runtime. Then, 
the programmer can progressively introduce static privilege anno- 
tations (function argument types, ascriptions) and remove :: ^.as- 
criptions, statically revealing required privileges. The static checker 
may reject the program if inconsistencies are detected, or it may 
accept the program and runtime errors may occur. As more static 
information is revealed, fewer dynamic checks are required. The 
effect discipline is hardened. 

2.4 Generic Effect Systems 

To avoid re-inventing gradual effects for each possible effect disci- 
pline, we build on the generic effect framework Marino and Mill- 
stein (M&M) 1 15 1, which we briefly describe in this section. 

The M&M effect framework defines a parameterized typing 
judgment <!>; V; E h e : T. It checks an expression under a set 
of privileges <3>, representing the effects that are allowed during 
the evaluation of the expression e. For instance, here is the generic 
typing rule for functions: 

*i;r,ar:Ti;EI-e:T a 

l-i^un 

$ ; r ; E h (Xx : Ti . e) e : {e}(Ti^>T 2 ) 

Since a function needs no specific permissions, any privilege set 
<1? will do. The function body itself may require privileges $1 and 
these are used to annotate the function type. We explain the tag e 
shortly. 

A given privilege discipline (mutable state, exceptions, etc.) is 
instantiated by defining two operations, a check predicate and an 
adjust function. The check predicate is used to determine whether 
the current privileges are sufficient to evaluate non-value expres- 
sion forms. To achieve genericity, the check predicate checkc is 
indexed by check contexts C, which represent the non-value ex- 
pression forms. The adjust function is used to evolve the available 
privileges while evaluating the subexpressions of a given expres- 
sion form. This function takes the current privileges and returns the 



2 In a static effect system, an effect ascription e {read} is directly anal- 
ogous to a type ascription 1 16]. Static effect ascriptions were introduced by 
Gifford and Lucassen [11]. 

3 This corresponds to the translation of terms from the untyped A-calculus 
to the gradually-typed A-calculus, which lifts all functions to the ? — >? type 
to introduce runtime checks 1231 . 



privileges used to check the considered subexpression. To achieve 
genericity, the adjust function adjust 4 is indexed by adjust con- 
texts A, which represent the immediate context around a given 
subexpression. 

To increase its overall expressiveness, the framework also in- 
corporates a notion of tags e, which represent auxiliary static in- 
formation for an effect discipline (e.g. abstract locations). Expres- 
sions that create new values, like constants and lambdas, are in- 
dexed with tags. The check and adjust contexts contain tag sets n 
so that checkc and adjust A can leverage static information about 
the values of subexpressions. To facilitate abstract value-tracking, 
type constructors are annotated with tagsets, so types take the form 
T = np. For more precise control, effect disciplines can associate 
tags to privileges e.g., read(ei), read(e 2 ), etc.Q 

For example, a check predicate for controlling mutable state is 
defined as follows: 

cheeky ($) read G $ 

check r ef „ ($) alloc G $ 

cheeky ~,r 2 (<I>) write G <& 

checkc ($) holds for all other C 

In this case, only state-manipulating expression forms have inter- 
esting check predicates, which simply require the corresponding 
privilege; the rest always hold. 

Since the assignment expression involves evaluating two subex- 
pressions (the reference and the new value), there are two adjust 
contexts. The {,:=t context, which corresponds to evaluating the 
reference to be assigned, and the tt :={. context, which corresponds 
to evaluating the assigned value. The J. denotes the subexpression 
for which privileges should be adjusted. The tagset n represents 
statically known information about any subexpressions that would 
be evaluated before the current expression. The f denotes a subex- 
pression that would be evaluated after the current expression. 

For certain disciplines, like mutable state, the adjust function 
is simply the identity for every context. But one could, for exam- 
ple, require that all subexpressions assigned to references must be 
effect-free by defining adjust as follows: 

adjust,^ ($) =0 

adjust A ($) = $ otherwise 

All typing rules in the generic system use check and adjust 
to enforce the intended effect discipline. For instance, here is the 
typing rule for assignment: 

adjust_|_. =t ($) ; T; E h ei : 7nRef Ti 
adjust^ !=i ($) ; T; E h e 2 : 7r 2 p 2 

Check 7ri :=- n - 2 (*) 7T 2 p2<:Tl 

T-Asgn — — 

$ ; r;Eh (ei:=e 2 ) e : {e}Unit 

The subexpressions ei and e 2 are typed using adjusted privilege 
sets. Their corresponding types have associated tagsets iTi that are 
used to adjust and check privileges. Note that in accord with left- 
to-right evaluation, adjust^. = ^ knows which tags are associated 
with typing e\. Finally, cheeky :=lr2 verifies that assignment is 
allowed with the given permissions and the subexpression tag sets. 
Subtyping is used here only to account for inclusion of privilege 
sets between function types. 



4 Gradual effects are compatible with effect systems that do not need tags. 
See Sec. [5] 
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For maximum flexibility, the framework imposes only two con- 
straints on the definitions of check and adjust: 

Property 1 (Privilege Monotonicity). 

• !f&i $2 then checkc^i) => checkc(3>2); 

• If$i C $ 2 then adjust A (<E>i) C adjust A ($ 2 ). 

Property 2 (Tag Monotonicity). 

' lfC\ C. C2 then checkc 2 ($) =>■ checker ($); 

• IfAi C A 2 then adjust^ ($) C adjust Ai ($). 

Privilege monotonicity captures the idea that once an expression 
has sufficient privileges to run, one can always safely add more. 
This corresponds to effect subsumption in many particular effect 
systems. In contrast, tag monotonicity captures the idea that more 
tags implies more uncertainty about the source of a runtime value. 
The jZ relation holds when contexts have the same structure and the 
tagsets of the first context are subsets of the corresponding tagsets 
of the second context. For example, ref 7rj C ref 7T2 if and only if 
7Ti C 7T2. In summary, check and adjust are order-preserving with 
respect to privileges and order-reversing with respect to tags. 

The framework can be instantiated with any pair of check and 
adjust functions that satisfy both privilege and tag monotonicity. 
The resulting type system is safe with respect to the corresponding 
runtime semantics: no runtime privilege check fails, so no program 
gets stuck. 

3. Gradual Effects as an Abstract Interpretation 

In this section we present a formal analysis of gradual effects, 
guided by the design principles presented in Sec. |2.2| We use 
abstract interpretation |4| to define our notion of unknown effects, 
and find that as a result the formal definitions capture our stated 
design intentions, and that the resulting framework for gradual 
effects is quite generic and highly reusable. 

3.1 The Challenge of Gradual Effects 

The central concept underlying gradual effects is the idea of un- 
known privileges, £. This concept was inspired by the notion of 
unknown type ? introduced by Siek and Taha 1 23 1, but this concept 
is not as straightforward to understand and formalize. 

First, gradual types reflect the tree structure of type names. Siek 
and Taha treat gradual types as trees with unknown leafs. Two 
types are deemed consistent whenever their known parts match up 
exactly. For instance, the types ? — > Int and Bool — > ? are 
consistent because their — > constructors line up: ? is consistent 
with any type structure. In contrast, privilege sets are unordered 
collections of individual effects, so a structure-based definition of 
consistency is not as immediately apparent. 

Second, under gradual typing, the unknown type always stands 
for one type, so casts always associate an unknown type with 
one other concrete type. On the contrary, the unknown privileges 
annotation 1 stands for any number of privileges: zero, one, or 
many. 

Third, simple types are related to the final value of a compu- 
tation. In contrast, privileges are related to the dynamic extent of 
an expression as it produces a final value. As such, defining what it 
means to gradually check privileges involves tracking steps of com- 
putation, rather than wrapping a final value with type information. 

Finally, as we have seen in Sec. |2.1| effect systems naturally in- 
duce a notion of subtyping, which must be accounted for in a grad- 
ual effect system. In general, subtyping characterizes substitutabil- 
ity: which expressions or values can be substituted for others, based 
on static properties. In prior work, Siek and Taha demonstrate how 
structural subtyping and gradual typing can be combined 1221 . but 



the criteria for substitutability differ substantially between struc- 
tural types and effects, so it is not straightforward to adapt Siek and 
Taha's design to suit gradual effects. 

Our initial attempts to adapt gradual typing to gradual effects 
met with these challenges. We found abstract interpretation to be 
an informative and effective framework in which to specify and 
develop gradual effects. The rest of this section develops the notion 
of unknown effect privileges and consistent privilege sets. The 
rest of the paper then uses the framework as needed to introduce 
concepts and formalize gradual effect checking. 

3.2 Fundamental Concepts 

This subsection conceives gradual effects as an instance of abstract 
interpretation. We do not assume any prior familiarity with abstract 
interpretation: we build up the relevant concepts as needed. 

For purpose of discussion, consider again the effect privileges 
for mutable state from Sec. 12. II 

$ G PrivSet = 7>({read, write, alloc}) 
3 G CPrivSet = P({read, write, alloc, 1}) 

We already understand privilege sets but we want a clear un- 
derstanding of what consistent privilege sets H — privilege sets that 
may have unknown effects — really mean. Consider the following 
two consistent privilege sets: 

Hi = {read} H 2 = {read, 1} 

The set Hi is completely static: it refers exactly to the set 
of privileges {read}. The set H2 on the other hand is gradual: 
it refers to the read privilege, but leaves open the possibility of 
other privileges. In this case, the 1 stands for several possibilities: 
no additional privileges, the write privilege alone, the alloc 
privilege alone, or both write and alloc. 

Thus, each consistent privilege set stands for some set of possi- 
ble privilege sets. To formalize this interpretation, we introduce a 
concretization function 7, which maps a consistent privilege set H 
to the concrete set of privilege sets that it stands forrl 

Definition 1 (Concretization). Let 7 : CPrivSet -> V (PrivSet) 

be defined as follows: 

7(H) 4 {H} ^ E 
n ' ]{(H\{i})U$|$G PrivSet} otherwise . 

Reconsidering our two example consistent privilege sets, we 
find that 

T(Si) = {{read}} 

, w , _ J {read, write}, {read, alloc},] 
71—2) \ {read}, {read, alloc, write} J 

Since each consistent privilege set stands for a number of possible 
concrete privilege sets, we say that a particular privilege set $ is 
represented by a consistent privilege set H if $ G 7 (H). 

If we consider these two resulting sets of privilege sets, it is 
immediately clear that Hi is more restrictive about what privilege 
sets it represents (only one), while H2 subsumes Hi in that it also 
represents {read}, as well as some others. Thus, Hi is strictly more 
precise than H2, and so 7 induces a precision relation between 
different consistent privilege sets. 

Definition 2 (Precision). Hi is less imprecise (i.e. more precise) 
than H2, notation Hi C H2, if and only if 7(Hi) C 7(82) 

Precision formalizes the idea that some consistent privilege sets 
imply more information about the privilege sets that they represent 



5 We introduce an abstraction function a in Sec. 3.4 
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than others. For instance, {read} is strictly more precise than 
{read, 1} because {read} C {read, 1} but not vice-versa. 

3.3 Lifting Predicates to Consistent Privilege Sets 

Now that we have established a formal correspondence between 
consistent privilege sets and concrete privilege sets, we can sys- 
tematically adapt our understanding of the latter to the former. 

Recall the checkc predicates of the generic effect framework 
(Sec. |2,4j , which determine if a particular effect set fulfills the re- 
quirements of some effectful operator. Gradual checking implies 
that checking a consistent privilege set succeeds so long as check- 
ing its runtime representative could plausibly succeed. We formal- 
ize this as a notion of consistent checking. 

Definition 3 (Consistent Checking). Let checkc be a predicate 
on privilege sets. Then we define a corresponding consistent check 

predicate checkc on consistent privilege sets as follows: 



checkc (E) 



checkc ($) for some $ £ 7(H) 



Under some circumstances, however, we must be sure that a 
consistent privilege set definitely has the necessary privileges to 
pass a check. For this purpose we introduce a notion of strict 
checking. 

Definition 4 (Strict Checking). Let checkc be a predicate on priv- 
ilege sets. Then we define a corresponding strict check predicate 
strict-checkc on consistent privilege sets as follows: 



strict-checkc (3) 



checkc ($) for all $ e 7(H). 



By defining both consistent checking and strict checking in 
terms of representative sets, our formalizations are both intuitive 
and independent of the underlying checkc predicate. Furthermore, 
these definitions can be recast directly over consistent privilege sets 
once we settle on a particular checkc predicate (cf. Sec.[5j. 

3.4 Lifting Functions to Consistent Privilege Sets 

In addition to predicates on consistent privilege sets, we must also 
define functions on them. For instance, the M&M framework is pa- 
rameterized over a family of adjust functions adjust^ : PrivSet — s> 
PrivSet, which alter the set of available effect privileges (Sec, |2.4} , 
Using abstract interpretation, we lift these to consistent adjust func- 
tions adjust A : CPrivSet — > CPrivSet. To do so we must first 
complete the abstract interpretation framework. 

Consider our two example consistent privilege sets. Each rep- 
resents some set of privilege sets, so we expect that adjusting a 
consistent privilege set should be related to adjusting the corre- 
sponding concrete privilege sets. The key insight is that adjust- 
ing a consistent privilege set should correspond somehow to ad- 
justing each individual privilege set in its represented collection. 

For example adjust A ({read, alloc}) should be related to the set 

{adjust A ({read, alloc})}, and adjust A ({read, £}) should be 
related to the following set: 

fadjust A ({read, write}) , adjust A ({read, alloc}) , 
1 adjust 4 ({read}) , adjust A ({read, alloc, write}) 

To formalize these relationships, we need an abstraction function 
a : V (PrivSet) — > CPrivSet that maps collections of privilege 
sets back to corresponding consistent privilege sets. For such a 
function to make sense, it must at least be sound. 

Proposition 1 (Soundness). T C ^(a(T))forallTe P(PrivSet). 

Soundness implies that the corresponding consistent privilege 
set a(T) represents at least as many privilege sets as the original 



collection T. A simple and sound definition of a is a(T) = {1}. 
This definition is terrible, though, because it needlessly loses infor- 
mation. For instance, a(7(Si)) = {^}, and since {1} represents 
every possible privilege set, that mapping loses all the information 
in the original set. At the least, we would like a(7(Hi)) = Hi. 

Our actual definition of a is far better than the one proposed 
above: 



Definition 5 (Abstraction). Let a : V (PrivSet) 

defined as follow^ 



CPrivSet be 



v(T) = 



<E> T = {$} 

(fl T ) U {1} otherwise. 



Proposition 2 (Optimality). Suppose TC^( 
Optimality ensures that a gives us not onl 



In words, abstraction preserves the common concrete privi- 
leges, and adds unknown privileges to the resulting consistent set if 
needed. As required, this abstraction function a is sound. 

Even better though, given our interpretation of consistent privi- 
lege sets, this a is the best possible one. 

I). Thena(T) C 3. 
a sound consistent 

privilege set, but also the most precise ondj In our particular 
case, optimality implies that 0(7(8)) = a for all S but one: 
«(7({read, write, alloc, £})) = {read, write, alloc}. Both 
consistent privilege sets represent the same thing. 

Using a and 7, we can lift any function / on privilege sets 
to a function on consistent privilege sets. In particular, we lift the 
generic adjust functions: 

Definition 6 (Consistent Adjust). 

Let adjust A : CPrivSet — s> CPrivSet be defined as follows: 

adjust 4 (H) = a ({adjust A ($) | $ g 7 (3)}) . 

The adjust function reflects all of the information that can be 
retained when conceptually adjusting all the sets represented by 
some consistent privilege set. 

The check and adjust operators are critical to our generic pre- 
sentation of gradual effects. Both definitions are independent of 
the underlying concrete definitions of check and adjust. As we 
show through the rest of the paper, in fact, the abstract interpreta- 
tion framework presented here time and again provides a clear and 
effective way to conceive and formalize concepts that we need for 
gradual effect checking. 

4. A Generic Framework for Gradual Effects 

In this section we present a generic framework for gradual effect 
systems. As is standard for gradual checking, the framework in- 
cludes a source language that supports unknown annotations, an in- 
ternal language that introduces runtime checks, and a type-directed 
translation from the former to the latter. 

4.1 The Source Language 

The core language (Fig. [TJ is a simply-typed functional language 
with a unit value, mutable state, and effect ascriptions e :: 3. The 
language is parameterized on some finite set of effect privileges 
Priv, as well as a set of tags Tag. The Priv set is the basis for 
consistent privileges CPriv, privilege sets PrivSet, and consistent 
privilege sets CPrivSet. The Tag set is the basis for tag sets TagSet. 
Each type constructor is annotated with a tag set, so types are 

6 For simplicity, we assume T is not empty, since a(0) = _L plays no role 
in our development. 

'Abstract interpretation literature expresses this in part by saying that a 
and 7 form a Galois connection^. 
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4> G Priv, £ G CPriv = Priv U {1} 
$ 6 PrivSet = P(Priv) , S G CPrivSet = V (CPriv) 

e € Tags . tv G 'P(Tags) 



S;T;She: T 



w 
V 

e 

T 

P 
A 

C 



unit | Ax : T . e \ I 

x I v I e e | e :: H 
(ref e) e | !e | (e := e) e 

7T p 

Unit | T^>T | Ref T 
It I Ti" II ref | | ! I 
| |:=t | 7T :=4 

7r 7r I ref 7r I !7r I 7r := 7r Check Contexts 



Prevalues 

Values 

Terms 

Types 
PreTypes 
Adjust Contexts 



Figure 1. Syntax of the source language 



annotated deeply. Each value-creating expression is annotated with 
a tag so that effect systems can abstractly track values. The type of 
a function carries a consistent privilege set S that characterizes the 
privileges required to execute the function body. 

The source language also specifies a set of adjust contexts A and 
check contexts C. Each adjust context is determined by an evalua- 



tion context frame / (Sec. 4.2 1. They index adjust A to determine 
how privileges are altered when evaluating in a particular context. 
Similarly, the check contexts correspond to program operations like 
function application. They index checkc to determine which priv- 
ileges are needed to perform the operation. 

Fig.[2]presents the type system. The judgment S; Y; E h e : T 
means that the expression e has type T in the lexical environment T 
and store typing E, when provided with the privileges 3. Based on 
the judgment, e is free to perform any of the effectful operations de- 
noted by the privileges in H. If the consistent privilege set contains 
the unknown privileges then e might also try any other effect- 
ful operation, but at runtime a check for the necessary privileges is 
performed. 

Each type rule extends the standard formulation with operations 
to account for effects. All notions of gradual checking are encapsu- 
lated in consistent effect sets 5 and operations on them. The [T-Fn] 
rule associates some sufficient set of privileges with the body of the 
function. In practice we can deduce a minimal set to avoid spurious 
checks. 

The [T-App] rule illustrates the structure of the non- value typing 
rules. It enhances the M&M typing rule for function application 
(similar to [T-Asgn] in Sec. \2A\ to support gradual effects. In 
particular, each privilege check from the original rule is replaced 
with a consistent counterpart: consistent predicates succeed as long 
as the consistent privilege sets represent some plausible concrete 
privilege set, and consistent functions represent information about 

what is possible in their resulting consistent set. adjust and check 
are defined in Sec. [3] and we use the same techniques introduced 
there to lift effect subtyping to a notion of consistent subtyping. To 
do so, we first lift traditional privilege set containment to consistent 
containment: 

Definition 7 (Consistent Containment). Hi is consistently con- 
tained in H2, notation Hi C H2 if and only if&i C $2 for some 
$1 G 7($i) and $2 G 7(H 2 J] 



T-Fn - 



3i;r,a;: Ti;E he: T 2 



3 ; r ; £ h (Xx: Ti .e) e : {e}Ti-^T 2 

T-Unit — 

3; T; E h unit e : {e}Unit 



T-Loc - 



E(7) = T 



3;T;E h l £ : {e}Ref T 



T-Var- 



I» = T 



3;r ; E h x: T 



T-App 



adjust^-) ;T;E h e\ : 7ri(Ti^i>T 3 ) 
adjust wi4 ,(3) ; T; E h e 2 : 7r 2 p2 

7ri(Ti^»T 3 ) < 7ri(7r 2 p2^T 3 ) cheeky (S) 
3; T; E h ei e 2 : T 3 



T-Eff- 



■i;r ; E h e: T 



T-Ref- 



3;T;E h (e :: Hi) : T 

adjust ref j_(3) ;T;E h e: np 
check ref ^(3) 



T-Deref 



3; T; E h (ref e) e : {e}Ref np 

adjust u (3) ; T; E h e: TrRef T 
cheeky (3) 



! We give C a simple direct characterization in Sec. 4.2 



3 ; r ; E He: T 

adjust^._*(3) ; T; E h ei : TriRef Ti 

adjust^ :=J _ (3) ;T; E h e 2 : 7r 2 p 2 

cheeky :=vr2 (3) 7r 2 p 2 < Ti 

1-Asgn — 

3;r;Eh(ei := e 2 ) e : {e}Unit 

Figure 2. Type system for the source language 



Consistent containment means that privilege set containment 
may hold unless we guarantee that it cannot. Of course, this claim 
must sometimes be protected with a runtime check in the internal 
language, as discussed further in the next section. Consistent sub- 
typing < is defined by replacing the privilege subset premise of 
traditional effect subtyping with consistent containment. 

T 3 < Ti T 2 < T 4 

7Tl C 7T 2 7Tl C 7T2 Hi C H2 

niP ~ n2f> TTlTi-^Ta < 7T2T 3 ^>T4 

This relation expresses plausible substitutability. Consistent con- 
tainment is not transitive, and as a result neither is consistent sub- 
typing. This property is directly analogous to consistent subtyping 
for gradual object systems 1221 . 

All other rules in the type system can be characterized as consis- 
tent liftings of the corresponding M&M rules. Each uses adjust^ 
to type subexpressions, and checkc to check privileges. 

Finally, [T-Eff] reflects the consistent counterpart of static ef- 
fect ascriptions, which do not appear in the M&M system. The rule 
requires that the ascribed consistent privileges be consistently con- 
tained in the current consistent privileges. Ascribing i delays some 
privilege checks to runtime, as discussed next. 

4.2 The Internal Language 

The semantics of the source language is given by a type-directed 
translation to an internal language that makes runtime checks ex- 
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e ::= . . . | Error | (T <= T)e Terms 

has $ e | restrict E e 
/ ::= □ e | v □ | (ref D) s Frames 

|!D | (D-e) £ | :=□)« 
g ::= / | (T 2 <S= Ti)D | has $ □ Error Frames 

| restrict E □ 

Figure 3. Syntax of the internal language 



H ; r ; S h e: T 



IT-App- 



adjust^H) ; T; S h ei : ^(Tj-^Ta) 
adjust^ (S) ; T; S h e 2 : 7r 2 p 2 

strict-check^ 1 W2 (H) 7Ti Ti — ^3 < : 7Ti 7r 2 p 2 ^>T3 
H; T; S h ei e 2 : T 3 
■ ; r;She:T 0 T 0 <:Ti Ti < T 2 



IT-Cast- 



IT-Has- 



H ; r ; Eh (T 2 <^Ti>e: T 2 
($U S) ; r ; S h e: T 



IT-Error- 



S h has <E> e: T S;T;Sh Error: T 

Si;r;She:T Hi < H 



IT-Rst- 



IT-Ref- 



IT-Deref- 



E; T; S h restrict Si e : T 

adjust ref ^(S) ; r ; S h e: Trp 
strict-check Te i tt(H) 
3;r;Sh (ref e) e : {s}Ref 7rp 

adjust,^ (E) ; T; S h e: TrRef T 
strict-checki K (S) 
S;T;S He: T 



adjustj_. =t (a) ; T; S h e 1 : TriRef 2\ 

adjust 7ri . =; (H) ;T;S h e 2 : 7r 2 p 2 

strict-check^ —^ (S) i" 2 p 2 <:ri 

IT-Asgn 

S ; r ; S h (ei := e 2 ) £ : {e}Unit 

Figure 4. Typing rules for the internal language 



plicit. This section presents the internal language. The translation 
is presented in Sec, |4.3| 

Fig.[3]presents the syntax of the internal language. It extends the 
source language with explicit features for managing runtime effect 
checks. The Error construct indicates that a runtime effect check 
failed, and aborts the rest of the computation. Casts (T <= T)e 
express type coercions between consistent types. The has operation 
checks for the availability of particular effect privileges at runtime. 
The restrict operation restricts the privileges available while 
evaluating its subexpression. 

Frames represent evaluation contexts in our small-step seman- 
tics. By using frames, we present a system with structural semantics 
like the M&M framework while defining fewer evaluation rules as 
in a reduction semantics. 

Static semantics The type system of the internal language (Fig.|4jl 
mostly extends the surface language type system, with a few criti- 



cal differences. First, recall that type rules for source language op- 
erators, like function application [T-App], verify effects based on 
consistent checking: so long as some representative privilege set is 
checkable, the expression is accepted. In contrast, the internal lan- 
guage introduces new typing rules for these operators, like [IT- App] 
(changes highlighted in gray). 

In the internal language, effectful operations must have enough 
privileges to be performed: plausibility is not sufficient anymore. 
As we see in the next section, consistent checks from source pro- 
grams are either resolved statically or rely on runtime privilege 
checks to guarantee satisfaction before reaching an effectful oper- 
ation. For this reason, uses of check are replaced with strict-check 
(Sec. |3 . 3 1 Def. |4j. Consistent subtyping < is replaced with a no- 
tion of subtyping < : that is based on ordinary set containment for 
consistent privilege sets and tags: 

Ti < : Ti T 2 < : T 4 

7Tl C 7T 2 7Tl C 7T 2 El C S 2 

7T1P<:7T2P B, H 2 

7TlJl >l2 <: K2±3 >I4 

The intuition is that an expression that can be typed with a given 
set of consistent permissions should still be typable if additional 
permissions become available. We formalize this intuition below. 

In addition to ordinary set containment, the internal language 
depends on a stronger notion of containment that focuses on stat- 
ically known permissions. A consistent privilege set represents 
some number of concrete privilege sets, each containing some 
different privileges, but most consistent privilege sets have some 
reliable information. For instance, any set represented by E = 
{read, ?} may have a variety of privileges, but any such set will 
surely contain the read privilege. We formalize this idea in terms 
of concretization as the static part of a consistent privilege set. 

Definition 8 (Static Part). The static part of a consistent privilege 
set, \-\ : CPrivSet — > PrivSet is defined as 



|H|=f>(H) 



The definition directly embodies the intuition of "all reliable 
information," but this operation also has a simple direct characteri- 
zation:|S|=S\U}F] 

Using the notion of static part, we define the concept of static 
containment for consistent privilege sets. 

Definition 9 (Static Containment). Si is statically contained in H 2 , 

notationSi < H 2 , if and only if |Hi| C |H 2 |. 

The intuition behind static containment is that an expression can 
be safely used in any context that is guaranteed to provide at least 
its statically-known privilege requirements. 

We need static containment to help us characterize effect sub- 
sumption in the internal language. Privilege subsumption says that 
if $ is sufficient to type e, then so can any larger set $' [25j. 
To establish this, we must consider properties of both strict-check 

and adjust. Conveniently, strict-check is monotonic with respect to 
consistent privilege set containment. 

Lemma 3. 

Ifstrict-checkc(S,i) and~E.\ C H 2 then strict-checkci^i)- 

To the contrary, though, adjust is not monotonic with respect 
to set containment on consistent privilege sets. Instead, it is mono- 
tonic with respect to static containment. 

Lemma 4. //"Hi < H 2 then adjust c (Hi) < adjust c (H 2 ) 
We exploit this to establish effect subsumption. 

9 The 7-based definition is useful for proving Strong Effect Subsumption 
(Prop.|3]below). 
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E-Ref- 



check ref {ei j ($) I 0 dom (/i) 
* I" (ref w £1 ) e , | M le 2 I w £l ] 



E-Asgn - 



check {El};={£2} ($) 

<E> h (l ei := w S2 ) e | /t — > unit e | fi[l i— > 1 



E-Deref- 



checki{ e }($) = v 

<& HZ e [ fj, — >• u [ fj, 



E-Frame - 



adjust A(/) ($) h e | ^ ->■ e' | // 



E-Has-T 

C $ $ h e | -» e' | /j? 

<3? h has e | — > has <E>' e' | // 
E-Rst-V 
E-App 

<& h (Aa;: Ti . e) £1 ui E2 | £t — > [«>,/i] e | /i 
E-Cast-Fn 



E-Has-V 



E-Error - 



<& h g[Error] | — > Error | 



E-Has-F 



<& h has <&' u | /i — » u | ^ $ h has e | p — > Error | fi 

0" = max 6 7(H) | C *} $" h c | /i -> e' | /i' 



$ h restrict "Bv \ fx —¥ v \ fx 



E-Rst- 



$ h restrict 3 e | — > restrict H e' | \j! 



E-Cast-Frame 

<I> h e | [i — > e! | ft' 

$ h (T 2 ^ Ti}e | ^ -> (T 2 <^= Ti}e' | M ' 

£ 6 7Tl 7Tl C 7T2 



E-Cast-Id 

£ £ 7Tl 7Tl C 7T2 

"3? h {tt2P <= Tt\p)w E \ jU — > w e | fJ, 



4 h <7r 2 T2i^T 2 2 <= 7riTii^>Ti 2 ) (Ax: Tn . e) e | /i -> (Ax: T 2 i . (T 22 <S= Ti 2 )restrict S 2 has (|Si| \ |H 2 |) [<< T " <= T =i)^)/x]e) £ | ;U 



Figure 5. Small-step semantics of the internal language 



Proposition 5 (Strong Effect Subsumption). 

If Si; T; E h e : T anrf Hi < H2, ffterc H2; F; E h e : T. 

Proof. By induction over the typing derivations Hi; F; E h e: T. 

□ 



Corollary 6 (Effect Subsumption). 

//'Hi; F; E h e : T arcrf Hi C H2, then ! 



; T; E h e: T. 



Proof. Set containment implies static containment. 



□ 



We now turn to the new syntactic forms of the internal language. 
Casts represent explicit dynamic checks for consistent subtyping 
relationships. The has operator checks if the privileges in $ are 
currently available. Its subexpression e is typed using the consistent 
set that is extended statically with 

The restrict operator constrains its subexpression to be ty- 
pable in a consistent privilege set that is statically-contained in the 
current set. Since 1 does not play a role in static containment, the 
set Hi can introduce dynamism that was not present in H. As we 
will see when we translate source programs, this is key to how as- 
cription can introduce more dynamism into a program. 

As it happens, we can use notions from this section to simply 
characterize notions that we, for reasons of conceptual clarity, de- 
fined using the concretization function and collections of plausible 
privilege sets. The concretization-based definitions clearly formal- 
ize our intentions, but these new extensionally equivalent charac- 
terizations are well suited to efficient implementation. 

First, we can characterize consistent containment as an exten- 
sion of static containment, and strict checking as simply checking 
the statically known part of a consistent privilege set. 

Proposition 7. 

1. Hi C H 2 if and only i/Hi C H2 or £ G H 2 . 



2. strict-checkc^S.) if and only (fcheckc(|E|). 

10 Note that <3? U H is the same as lifting the function /(<&') = 
<3> C 3 is the same as lifting the predicate P(<£>') = <t> C 



<I> U $', and 



Furthermore, we can characterize consistent checking based on 
whether the consistent privilege set in question contains unknown 
privileges. 

Proposition 8. 

1. If 1 £ H then checkc(H) if and only i/checkc(PrivSet). 

2. If 1 H then checkc(H) if and only !/checkc(H). 

Dynamic semantics Fig. [5] presents the evaluation rules of the 
internal language. The judgment $ h e [ fi — >■ e' [ fi' means that 
under the privilege set $ and store y,, the expression e takes a step 
to e and (/. Effectful constructs consult $ to determine whether 
they have sufficient privileges to proceed. 

The has expression checks dynamically for privileges. If the 
privileges in $ are available, then execution may proceed: if not, 
then an Error is thrown. Note that in a real implementation, has 
only needs to check for privileges once: the semantics keeps has 
around only to support our type safety proof. 

The restrict expression restricts the privileges available in 
the dynamic extent of the current subexpression. The intuition is 
as follows. H represents any number of privilege sets. At least 
one of those sets must be contained in <E> or the program gets 
stuck: restrict cannot add new privileges. So restrict limits 
its subexpression to the largest subset of currently available privi- 
leges that H can represent. In practice, this means that if H is fully 
static, then H represents only one subset of $ and the subexpres- 
sion can only use those privileges. If 1 £ H, then H can represent 
all of $, so the privilege set is not restricted at all. This property of 
restrict enables ascription to support dynamic privileges. 

Since function application is controlled under some effect dis- 
ciplines, the [E-App] rule is guarded by the check app predicate in- 
herited from the M&M framework. If this check fails, then the pro- 
gram is stuck. More generally, any effectful operation added to the 
framework is guarded by such a check. These checks are needed to 
give intensional meaning to our type safety theorem: if programs 
never get stuck, then any effectful operation that is encountered 
must have the proper privileges to run. This implies that either the 
permissions were statically inferred by the type checker, or the op- 
eration is guarded by a has expression, which throws an Error if 
needed privileges are not available. It also means that thanks to 
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type safety, an actual implementation would not need any of the 
checkc checks: the has checks suffice. This supports the pay-as- 
you-go principle of gradual checking. 

Higher-order casts incrementally verify at runtime that consis- 
tent subtyping really implies privilege set containment. In particu- 
lar they guard function calls. First, they restrict the set of available 
privileges to detect privilege inconsistencies in the function body. 
Then, they check the resulting privilege set for the minimal priv- 
ileges needed to validate the containment relationship. Intuitively, 
we only need to check for the statically determined permissions 
that are not already accounted for. 

To illustrate, consider the following example:{read, alloc} C 
{read, 1} because alloc could be in a representative of {read, i}, 
but {read, alloc} g {read, ^} since that is not definitely true. 
Thus, to be sure at runtime, we must check for 
{read, alloc} \ {read, ^,}| = {alloc}. Note that the rule 
[E-Cast-Fn] uses the standard approach to higher-order casts due 
to Findler and Felleisen [8|. As a formalization convenience, the 
rule uses substitution directly rather than function application so 
as to protect the implementation internals from effect checks and 
adjustments. In practice the internal language would simply use 
function application without checking or adjusting privileges. 

Type safety We prove type safety in the style of Wright and 
Felleisen 1271 . Program execution begins with a closed term e as 
well as an initial privilege set The initial program must be well 
typed and the privilege set must be represented by the consistent 
privilege set 3 used to type the program. Under these conditions, 
the program will not get stuck. 

Our statements of Progress and Preservation introduce the rep- 
resentation restrictions between consistent privilege sets and the 
privilege sets used as contexts for evaluation. These restrictions can 
be summarized in that typing ensures that evaluation does not get 
stuck in any particular context represented statically]^] 

Theorem 9 (Progress). Suppose S; 0; E h e: T. Then either e is 
a value v, an Error, or $ h e | /i — > e | pf for all privilege sets 
"3? G 7(2) and for any store fi such that 0 | £ h /z. 

Proof. By structural induction over derivations of H; 0; £ h e: T. 

□ 

Theorem 10 (Preservation). 7/S; T; £ h e : T, and 

<fr h e I — > e fi' for $ G 7(H) and F \ £ h p, then 

T I £' h p! and S; T; £' h e' : T' for some T < : T and £' D £. 

Proof. By structural induction over the typing derivation. Preserva- 
tion of types under substitution for values (required for [E-App]) 
and for identifiers (required for [E-Cast-Fn]) follows as a standard 
proof since neither performs effects. □ 

4.3 Translating Source Programs to the Internal Language 

Fig.|6]presents the type-directed translation of source programs to 
the internal language (the interesting parts have been highlighted). 
The translation uses static type and effect information from the 
source program to determine where runtime checks are needed 
in the corresponding internal language program. In particular, any 
consistent check, containment, or subtyping that is not also a strict 
check, static containment, or static subtyping, respectively, must be 
guarded by a has expression (for checks and containments) or a 
cast (for subtypings). 

Recall from Sec. |4.2| that the has expression checks if some 
particular privileges are available at runtime. The translation sys- 
tem determines for each program point which privileges (if any) 

1 1 We also proved soundness for a minimal system with neither tags nor 
state. 



C-Fn- 



Si;r,a;: Ti; S h e => e' : T 2 



H ; r ; S h (Xx: Ti .e) e (Xx: Tj . e') e : {ejT^Ti 

C-Unit — — 

a; T; £ r unit £ => unit £ : {ejUnit 

I» = T 



C-Var— 



C-Loc- 



S;r;Shi=M: T 
S(0 = T 



I- l e l e : {e}Ref T 

adUust 4t (3) ; r;Shei => e{ : 7ri(Ti^-T 3 ) 
adjust 7ri ^(H) ; T; S h e 2 => e' 2 : tv 2 P2 

>\ = ( (( 7 r 1 ( 7 r 2 p2^T 3 ) 4= 7u(Ti^T 3 )» e[) 



C-App 



check vri ^ 2 (=) 




:) 




H ; r ; E h ei e 2 => 


insert-has ?(<!>, e" e 2 ) 


: T 3 



Si;T;E h e => e' : T 


Si £H 


*=(|Si|\|S 


1) 


H ; r ; S h (e :: Si) 


insert-has ? (<!> , restrict Hi e') 


: T 



C-Ref 



adjust ref 1 (H) ; T; S h e e' : irp 



check ref ,r(3) 


* = A r . fw (S) 




H;T;E h (ref e) E => 


insert-has ?(<&, (ref e') £ ) 


: {e}Ref np 



C-Deref- 



adjust u (H) ;r;Ehe=>e': TrRef T 
check, T (H) * = A ta (H) 

H;r ; Sh!e=> insert-has?{<l>, le') : T 



C-Asgn 



adjust, :=t (H) ; T; S h ei => ei : TuRef T\ 



dwck B - 1 : =T2 (S) 


T2P2 < Ti 


$ = A Wi:= ,t 


a (S) 




H;r ; Sh (ei :=e 2 ) £ 


insert-has ?(<!>, (e'j := e 2 ) £ ) 


: {e}Unit 



Figure 6. Translation of source programs to the internal language 



must be checked. Since the generic framework imposes only priv- 
ilege and tag monotonicity restrictions on the check and adjust 
functions, deducing these checks can be subtle. 

Consider a hypothetical check predicate for a mutable state 
effect discipline: 



checkc ($) 



read G "3? or write G $. 



Though strange here, an effect discipline that is satisfied by one 
of two possible privileges is generally plausible, and in fact satis- 
fies the monotonicity restrictions. When, say, the consistent check 

checkc ({l}) succeeds in some program, which privileges should 
be checked at runtime? 

The key insight is that the internal language program must check 
for all privileges that can produce a minimal satisfying privilege set. 
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In the case of the above example, we must conservatively check for 
both read and write. However, we do not need to check for any 
privileges that are already known to be statically available. 

We formalize this general idea as follows. First, since we do not 
want to require and check for any more permissions than needed, 
we only consider all possible minimal privilege sets that satisfy 
the check. We isolate the minimal privilege sets using the mins 
function: 

mww(T) = {$ G T | W G T.$' £ $}. 

Given some consistent privilege set S, we identify all of its plau- 
sible privilege sets that satisfy a particular check, and select only 
the minimal ones. In many cases there is a unique minimal set, but 
as above, there may notrjTo finish, we coalesce this collection 
of minimal privileges, and remove any that are already statically 
known to be available based on 3. These steps are combined in the 
following function. 

Definition 10 (Minimal Privilege Check). Let C be some checking 
context. Then define Ac : CPrivSet — > PrivSet as follows: 

Ac (3) = (\)mins({$ G 7(H) | checkc($)})) \ |S| 

The Ac function transforms a given consistent privilege set 
into the minimal conservative set of additional privileges needed 
to safely pass the checkc function. For instance, the [C-App] 
translation rule uses it to guard a function application, if need be, 
with a runtime privilege check. These checks are introduced by the 
insert-has? metafunction. 



insert-has ?(<E>, e) = 



e if $ = 0 

has $ e otherwise 



Note that the metafunction only inserts a check if needed. This 
supports the pay-as-you-go principle of gradual checking. 

Since [C-App] also appeals to consistent subtyping, a cast may 
be introduced in the translation as well. For this, we appeal to a cast 
insertion metafunction: 



((T2 <= 71»e 



e 

(T2 



Ti>e 



ifTi <: T 2 
otherwise. 



Once again, casts are only inserted when static subtyping does not 
already hold. 

The [C-Eff] rule translates effect ascription in the source lan- 
guage to the restrict form in the internal language. If more priv- 
ileges are needed to ensure static containment between Hi and 3, 
then translation inserts a runtime has check to bridge the gap["| 

Crucially, the translation system preserves typing. 

Theorem 11 (Translation preserves typing). If E; T; E h e =>■ 

e' : T in the source language then 3; T; E h e : T in the internal 
language. 



Proof. By structural induction over the translation derivation rules. 
The proof relies on the fact that Ac (3) introduces enough runtime 
checks (via insert-has?) that any related strict-checked) predi- 
cate is sure to succeed at runtime, so those rules do not get stuck. 
The instance of insert-has? in the [C-Eff] rule plays the same role 
there. □ 

12 One could retain precision by extending our abstraction to support dis- 
junctions of consistent effect sets, at the cost of increased complexity in the 
translation and type system. 

13 The formula for $ is analogous to the Ac operation for checkc- 



e 


::= ... raise Sr(e) 


Terms 




| try e handle st(x) . e 
::= / | try □ handle St e 




/ 


Source Frames 


/' 


: := ( Original Source Frames) 
raise st(D) 


Propagating Frames 


C 


::= ... raise St(t^) 

| try 7r handle st f 


Check Contexts 


A 


::= ... raise St(40 


Adjust Contexts 



I try J, handle St t 
Figure 7. Syntax for a Gradual Effect System with Exceptions 



check. 



E-Raise-Frame - 



-({•})(*) 



E-Try-V 



E-Try-T- 



<I> h /'[raise St(v)] | M — > raise Sf(v) \ /j, 
check try 

{•} handle s T t 

(*) 

<E> h try v handle Sf (i).e | fj, — > v \ fjt 
check try 

0 handle s-^t (*) 



<& h try raise sj<(v) handle sj(i).e | — ► ["/t] e | lie 



E-Try-F 



check,. 



l *raise s Tl ({•}) t*^) 

<£> h try raise sy, (v) handle sj> 2 (x).e \ fi —> raise ST t {v) \ ^ 

Figure 8. Evaluation rules added to the operational semantics for 
a system with exceptions 



5. Example: Gradual Effects for Exceptions 

In this section we show how to use our framework to define sys- 
tems with richer language features. We extend the language with 
exception handling and introduce an effect discipline that verifies 
that every raised exception is caught by some handler. We intro- 
duce new syntax; privilege and tag domains; adjust and check op- 
erations and contexts; and typing, translation, and evaluation rules. 
Note that the example system is general enough to allow different 
effect disciplines for exceptions. 

The language introduces an infinite set of exception construc- 
tors st, which are indexed on the type T of argument that they 
carry as a payload. An exception is triggered by the raise s:r(e) 
expression, which indicates that the expression e should be evalu- 
ated to a value of type T, wrapped in the exception constructor, and 
raised. An exception handler, try ei handle sr{x).e2, attempts to 
evaluate the expression ei. If successful, its result is returned; if e± 
raises a st exception, it binds the payload to x and evaluates e2. 

We also introduce new adjust and check contexts. These con- 
texts are used to parameterize different effect disciplines over the 
same constructs. They are used by the adjust and check functions 
in the operational semantics, by the type system and the translation 
algorithm. Following M&M, we define a new check context for 
each new redex and a new adjust context for each new evaluation 
frame. 

Fig. [8] presents the semantics for exceptions in our system. 
Exceptions propagate out of evaluation frames by rule [E-Raise- 
Frame] until they are caught by a matching handler. Since handlers 
are also evaluation frames, we must distinguish the rest of the 
evaluation frames from handlers. As presented in Fig. [7] we call 
non-handler frames "Propagating Frames". 

A try handler first reduces the guarded expression. If it is a 
value, the exception handler is discarded through rule [E-Try-V]. If 
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adjust raise STW (S);F;S\-e: T 
check raise ST ({.})(H) 
S ; r ; S h raise s T (e): T' 

4,handle stI"^ 1- * ' ' 

S h ei : Ti 
3; T, x^ S h e 2 : T 2 T 2 < Ti 

Check try {.}i!aiidle s r t( = ) 

H;T;S h try e\ handle s-r(x).e 2 : Ti 



Figure 9. Source language typing rules for exceptions 



the guarded expression reduces to an exception whose constructor 
matches the handler, rule [E-Try-T] substitutes the payload value 
in the handling expression. If the constructor does not match the 
handler, the exception is propagated by rule [E-Try-F], and the 
handler discarded. 

Rule [E-Try-T] uses 0 in the check context instead of a tagset 
because the guarded expression produced an exception instead 
of a value. The type system does not relate the type of the ex- 
ception payload to the type of the guarded expression, so when 
check is evaluated it cannot access tag information related to the 
guarded expression. We followed the most conservative strategy 
for this case. Thanks to the tag monotonicity property, we know 
that check holds with 0 if it holds for any particular it because 
try 0 handle st t E "try ty handle st t- 

The new source language typing rules are presented in Figure|9] 
The corresponding typing rules for the internal language follow 
the same pattern as for rules in the general framework: check is 
replaced by strict-check and < is replaced by < : .In the translation 
system, the rules introduce Ac and insert-has?. 

As presented so far, our gradual effect system with exceptions 
does not enforce any particular effect discipline. To do so, we need 
to define both a domain for privileges and concrete check and 
adjust functions. We instantiate privileges Priv to be the exception 
constructors (of the form st), and provide the following definitions 
for check and adjust, which capture the standard effect discipline 
for exceptions: 

check raise srW ($) -£=>■ st e $ 
checkc ($) holds for all other C 

adjust trja handle ST f ($) = $u{s T } 
adjust A ($) = $ otherwise 

Note that this effect discipline does not require tags, so techni- 
cally we use a singleton set for the universe of tags (e 6 {•})• In 
practice the tags can be removed altogether. 

Implementation With a concrete effect discipline, an instance of 
the general effect system can be specialized to produce concrete 
operational semantics, type system and translation algorithm rules, 
inlining the calls to check and adjust. Figure [10] presents special- 
ized translation rules for the concrete discipline we have chosen. 
These rules directly incorporate the semantics of the insert-has? 
function, separating its two cases across two separate translation 
rules. Since the only non-trivial check context in the effect disci- 
pline is raise sr(7r), we provide separate rules only for raise 
using the feasible values for A raise ST (x) in each case (0 or {st}). 

Illustration By making the exception checking discipline grad- 
ual, we achieve a more expressive language. Consider the following 
function, which also uses conditionals and arithmetic expressions: 



3; T; £ h e => e! : Ti 

fa}E5 

3; T; S h raise sj*, (e) => raise st x (e') : T 2 

3; T; £ h e =>• e' : Ti 

3; T; £ h raise s^ (e) has \st ± } raise st x (e') : T 2 

3U {s T };T;S h ei => e[ : Ti 
3 ; r,x: T;£ h e 2 => e' 2 : T 2 T 2 < : Ti 
e' = try e' x handle ST(x).e' 2 

3; T; S h try ei handle st(x).C2 => e' : Ti 



Figure 10. Implementation version of the translation rules for a 
system with exceptions 



let squared = A/: Int^^Int . (Xx: Int . (f(x * x)) :: 0) 
positive = Xx: Int . if x > 0 then x else raise sjm(x) 
in (squared positive) 

A key property of the positive function is that it never raises 
an exception when applied to a non-negative argument. On the 
other hand, function squared always calls / with x * x as an 
argument, which is never negative. We therefore know that the 
function produced by evaluating (squared positive) never raises 

an exception, so we would like to type it as Int— ^ Int. A static 
effect system is too restrictive to do so, but a gradual effect system 
provides the flexibility to assign the desired type to the function. 
The squared function's parameter is declared to have type 

Int— ^Int , for some H. Without gradual effects, the only options 
for S are either 3 = 0, in which case the type system will reject the 
application(sgitarec( positive) because the argument requires too 
many privileges, or {si nt } C 3, which means the returned function 

cannot be typed as Int— — >Int. 

In the gradual exception system, we can annotate function 
positive to hide its side effects, delaying privilege checking to 
runtime, and annotate function squared to allow functions that 
may throw exceptions, as in the following: 

letsquared = A/: Int -^i Int . (Xx: Int . (f(x * x)) :: 0) 

positive = Xx : Int . (if x > 0 then x else raise sj a t (x)) :: {:} 
in (squared positive) 

The translation algorithm then produces the following program in 
the intermediate language: 

let squared = A/: Int-^ilnt. 

Ax: Int . 
restrict 0 

(((Int-^lnt <= Int-^ilnt)/)(a; * x))) 
positive = Xx: Int. 

restrict {^} 
if x > 0 
then x 

else has {si nt } raise si n t(a;) 

in (squared positive) 

In this program, application (squared positive) can be typed as 

Int— ^-Int, as desired. Given the properties of integer numbers, 
the else branch in the body of positive will never be executed. 
The higher-order cast for / in the body of squared never fails be- 
cause rule [E-Cast-Fn] only introduces restrict 0 has 0checks. 
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Effect errors are not exceptions Gradual Effects for Exceptions 
is more expressive than simply raising uncaught exceptions. Trig- 
gering an Error instead of propagating the exception prevents the 
system from following implicit exceptional control flows, where 
an outer handler catches an exception that was locally forbidden. 
The following example demonstrates how this behavior can affect 
evaluation of a program: 

let positive = Ax : Int . (if x > 0 then x else raise si nt (x)) 

nonzero = Xx : Int . if x = 0 raise si nt (x) else x 
in try 

nonzero ((positive —1) :: 0) 
handle si n t(x) 
print "0 is an invalid argument" 

The handler in the let body is designed to catch the exceptions 
thrown by the body of nonzero. To this end, the code uses an effect 
ascription to ensure that the argument to nonzero does not throw 
any exception. 

At the same time, the program reuses the positive function in- 
troduced in the previous example, but applies the function to a neg- 
ative number. Given this incorrect argument, positive attempts to 
raise an exception. An effect ascription to the 0 privilege set forces 
the application to not raise any exception at all. This inconsistent 
behavior is caught at runtime by the gradual effect discipline. 

We purposely used the same label for exceptions in positive 
and in nonzero. If the system simply threw the uncaught exception 
in positive, the handler would take control even though it was 
not designed for that exception. Instead, since positive has no 
exception raising privileges, the system triggers an Error just before 
it would have thrown the exception. Evaluation thus terminates 
without control ever reaching the exception handler, which was 
designed for failures of nonzero only. 

6. Related Work 

In the realm of effect systems, the most closely related work is the 
generic framework of Marino and Millstein 1 15 1, which we have 
extensively discussed in this paper, because we build upon it to 
formulate gradual effect checking in a generic setting. 

Rytz et al. 1171 develop a notion of lightweight effect polymor- 
phism, which lets functions be polymorphic in the effects of their 
higher-order arguments. The formulation is also generic like the 
M&M framework, although there are more technical differences; 
most notably, the system is formulated to infer effects instead of 
checking privileges. An implementation of the generic polymor- 
phic framework has been developed for Scala, originally only with 
IO and exceptions as effects. More recently, a purity analysis has 
been integrated in the compiler plugin [ 18 1. The effect system has 
been applied to a number of Scala libraries. Interestingly, Rytz et 
al. report cases where they suffer from the conservativeness of the 
effect analysis, similar to the example of Sec. [2] To address this, 
Rytz recently introduced an ^unchecked annotation. Although it 
is called a cast, it is an "unsafe cast", since no dynamic checking is 
associated to it; i.e. it is just a mechanism to bypass static checking. 
We believe our work on gradual effect checking could be of direct 
practical use in Scala, and intend to pursue that route. 

While there is a long history in the area of combining static 
and dynamic checking, the gradual typing approach of Siek and 
Taha [23| has been particularly successful and triggered many de- 
velopments. Its main contribution was to identify the notion of con- 
sistency as a key to support the full spectrum of static-to-dynamic 
typing. Originally developed for functional languages, it has been 
extended in several directions, including structural objects 1221 and 
generics 1 14 1. Most directly related to this work is the application 
of the gradual typing principles to other typing disciplines, such as 
ownership types, typestates, and information flow typing. 



Wolff et al. 1 26 1 develop gradual typestate checking. Typestates 
reflect the changing states of objects in their types. To support flex- 
ible aliasing in the face of state change, the language provides ac- 
cess permissions to support rely-guarantee reasoning about aliases, 
and state guarantees, which preserve type information for distinct 
aliases of shared objects. 

Sergey and Clarke propose gradual ownership types 1211 . Like 
gradual typestates, gradual ownership expresses and dynamically 
tracks heap properties. While typestate focuses on objects changing 
state, ownership controls the flow of object references. 

Disney and Flanagan [6] explore the idea of gradual security 
with a gradual information flow type system. Data can be marked 
as confidential, and the runtime system ensures that it is not leaked. 
This dynamically-checked discipline is moved towards the static 
end of the spectrum by introducing security labels on types. 

Extensions to contract systems for higher-order functions |9|, 
such as computational contracts 1 19 20 1 and temporal contracts [ ; 7j, 
have the ability to monitor for the occurrence of specific (sequences 
of) execution events, in particular effectful operations. These ap- 
proaches rely on full runtime monitoring; it is not clear if they could 
be reconciled with the pay-as-you-go model of gradual checking. 

As far as we know, none of the existing approaches to gradual 
checking relies on abstract interpretation to develop an account of 
uncertainty. While it remains to be studied, it seems that the abstract 
interpretation approach we follow here could be used to investigate 
existing and as-yet unexplored notions of gradual checking. 

7. Conclusion 

The primary contribution of this paper is a framework for devel- 
oping gradually checked effect systems for any number of effect 
systems that can be couched in the M&M framework. Using our 
approach, one can systematically transform a static effect discipline 
into one that supports full static checking, full dynamic checking, 
and any intermediate blend. We believe that gradual effect check- 
ing can facilitate the process of migrating programs toward a stati- 
cally checked effect discipline, as well as bringing dynamic effect 
checks to languages that have no such checks whatsoever, and leav- 
ing wiggle room for programs that can only partially fit an effect 
discipline. To empirically evaluate this claim, we intend to imple- 
ment our framework in the Scala language, and extend it to support 
the effect features that the language already provides. 

Initially, we relied on the principles of gradual checking and our 
intuitions to guide the design, but found it challenging to develop 
and validate our concepts. We found abstract interpretation to be an 
effective framework in which to develop and validate our intuitions. 
Using it we were able to generically define the idea of consistent 
functions and predicates, as well as explain and define auxiliary 
concepts such as strict checking and static containment. We believe 
that, in addition to gradual effects, other gradual checking notions 
could be fruitfully investigated in this framework. In particular, we 
intend to extend our system to support full gradual type-and-effect 
systems, which depend on gradual effects as an initial step, and 
define blame tracking for effect casts. 
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